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METHOD FOR SIMULATING A COMMUNICATION NETWORK THAT COSIDERS QUALITY OF SERVICE 



5 ★ * * ' 

Field of the invention 

The present invention refers to techniques for 
simulating . communications networks such as, for 
example, radio-mobile cellular networks, 
10 Simulation is an essential • step in planning, 

■ 

designing/' realising and managing such networks, above 
• all in view of^ optimising network performances. In 
particular, simulation plays an important role both at 

» 

check level for new planning network, and at update and 
15 optimisation level of performances of an already set-up 
network. . •■ 

The invention has been devised paying particular 
care to' the setting, up of such simulation techniques as 
to produces parameters 'that can be used for evaluating 
20 the- so-called Quality of Service (QoS) of the simulated 
network. " , ■ 

Description of the prior art 

A communications network, such as a radio-mobile 
cellular network, of fers ' quality of service when it is 
25. able to, deal with the traffic produced, by different 

■ 

applications in such to way . as to satisfy their 
requests. 

The .quality of service is therefore an indicator 
of the .network, capability of offering a different 

30 management to different data flows. In general, the 

■ 

quality of service must be present along the whole data 
flow path (end-to-end) . 

It is known that there are cellular radio-mobile 
network system simulators characterised by an object 

* 

35 architecture, such as disclosed, for example, in WO-A- 
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02/104055. According to. the object approach, the 
elementary decomposition unit is not the operation 
(method), - but the object, meant as model of a real 

* 

entity (a real -world object) . 
5 It is known that in such simulators there are 

modules or devices adapted to simulate the behaviour of 
physical network . devices. It ■ is also known that a 
typical problem in developing system simulators, 
realised with such architecture, is linked to the need 

10 of managing the simultaneous simulation of calls 
realised by . users that use services having different 
quality requirements . 

It is also known that in such simulators it is 
possible to simulate different types of services, but 

15 these . different services are completely defined 
previously ' inside the. simulator and cannot be 
dynamically modified by a user. For example, in a 
simulator as disclosed in WO-A-02/104055 it is possible 
to simulate' calls with GSM voice service and calls with 

20 GPRS data service. The user of such simulator can only 
set, at the simulation beginning, how many simulated 
users perform GSM voice calls and how many perform GPRS 

data calls. 

» 

In JP07283778A2 instead a system is disclosed for 

» 

25 globally evaluating the arrangement or realisation of a 
cellular network, taking also into account costs and 
quality of supplied service. The case of having many 
QoS profiles is not dealt with. 

Moreover, in US20030045298A1 a method is described 

30 for foreseeing the behaviour of an application using 
the results of a network simulation. It is provided to 
get the application responses when the speed and the 
simulated area position change. To do this, maps of QoS 
of the simulated area are used and, through the values 

35 of QoS being found in. the maps, the behaviour of the 
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♦ ■ « 

considered application is . provided in the various 

■ 

positions inside the area. It is therefore only a 
different possible use of .the simulation results that 

i 

a traditional simulator is able to furnish with respect 
5 to a given application. 

Purpose and synthesis of the present invention 
In the known type of simulators, particularly for 
cellular networks, it is not. possible for the user to 
dynamically describe the applications or the services 
10 to simulate (for # instance: sounds, web browsing, 
streaming audio and/or video, e-mail,...). Besides it is 
not possible to associate to every simulated user a 
potentially different service from that of the other 
users. Particularly, it is not possible to dynamically 
15 define a QoS profile that contains the characteristics 
of a" particular service; neither it is possible to 
define a QoS profile 'for every simulated user that is 
different from the profiles of the other users. 

This means f that the known solutions allow 
20 simulating a communications network through objects 

r 

that model respective network devices, simulating 
through such objects the network services delivery 
according to respective quality profiles of service, 
that however are referred to a certain user typology; 
25 the various users, for instance "sound user", "data 
user", etc., are fixed, particularly as regards the 
service parameters (available band, transfer times, 

transfer speed,-...) 7 

* 

In other words, in the solutions according to the 
30 known art, it is at most possible to only simulate a 
very narrow number of predefined "populations" of 
services or user typologies. The Applicant has observed 
that this corresponds to a representation that is a 
great deal far away from the current operating reality 

r 

35 of a- communications network, where a high number of 
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services corresponding to a wide range of possible- 
delivery and use , modes are mutually coexisting and 
interacting, particularly as regards the use of the 
network resources . 
5 Object of the present invention is therefore 

.overcoming the above-mentioned drawbacks , both the mode 
with which dynamically describing the different 
services inside the simulator, and the way of managing 
the possibility that , every user can use a different 

10' service from those used by the other users, being able 
to be determine. Everything .in a dynamic picture that 
corresponds in a more faithful and direct way to the 
operating reality of a communications network, in order 
to. allow planning, designing, realising, managing and 

15 optimising the network in terms of QoS . This also as 
regards the possibility of defining new service 
profiles to simulate, in a flexible way and/or without 
having to proceed to the complete re-design of the 
correspondents simulation objects, also making the 

■ 

20 management of services at simulation level more 
slender. 

According to the present invention, such object is 
reached due to 3 method having the characteristics 
recalled in specific way in the claims that follow. The 
25 . invention also deals with the corresponding system 
(simulator) , the simulation objects herein included, 
the network deriving from the application of the method 
according to the invention^ as well -as a -corresponding 
information product loadable in the memory of at least 

* • 

30 one electronic computer and comprising portions of 

» ~* 

software code to perform the method according to the 
invention when the product is executed on' a computer: 
in this context such term has to be deemed entirely 
equivalent to the mention of readable means from a 
35 computer comprising instructions to check a network of 
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computers in order to perform a method according to the 
invention.. The reference to "at least one electronic 
computer"- is obviously aimed to show the possibility to 
perform the solution according to the invention in a 
5 de-centralized context. 

Substantially, the .currently-preferred embodiment 
of the invention " provides for the selective 
identification of at - least one quality of service 

# 

profile. The simulation objects are then dynamically 
10 configured then for simulating the service delivery 
corresponding to the quality of service profile that 

s 

has been selectively identified. 

In the currently-preferred embodiment, the 
solution "herein described solves the above-mentioned 

* 

15 technical problem through one or more of the following 
innovative elements : 

- introduction of such a typology of "quality of 
service profile" that every profile describes the 

quality requirements of a single service; by setting 

> 

20 different requirements, the profile defines a different 
service; 

- identification of parameters that define every 
service: > the service quality requirements can be 
expressed through different parameters (service class , 

25 transfer " delay, maximum bit rate respectively for 
uplink section and for downlink section, guaranteed bit 
rate respectively for uplink section and for downlink 
section) ; every value given to service quality 

■ ■ 

parameters univocally defines a type of service." Such 
30 parameters are grouped together and constitute the 
attributes of the single "quality of service profile" : 
the simulator user can set as input the values of 
different parameters of every profile of quality, 
dynamically varying the simulated services; 
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- possibility to define different service quality 
profiles for every simulated user: every simulated user 
has at least his own "quality of service profile" that 
can be set by the user; in this way it is possible to 

5 perform simulations in which every user can use a 
different service from those used by the other users. 

It is thereby possible to determine both the mode 
with which the different services inside the simulator 
can be determined, and the way of managing the 
10 possibility that every user can use a different service 
from those used by the other users. 

The simulation thereby corresponds in a more 
faithful and direct way to the operating reality of a 

* 

communications network, and allows planning, designing, 
15 realising, managing and optimising the network in terms 
of QoS . 

It is then allowed to define new service profiles 
to simulate in a flexible way and/or without having to 
proceed with. the complete re -design of the 
20 corresponding simulation objects, also making the 
service management at simulation level more slender. 

Brief description of the attached drawings 

» 

The' invention will be described, merely as a non- 
limiting example, with reference to the attached 
25 . drawings, in which: 

- figure 1 is a functional approximate diagram of 
the simulator of the herein-d.escribed type, 

- figures 2 and 3 show possible configurations of 
the aforesaid simulator, 

30 - figure 4 shows a possible definition of quality 

of service profile within a simulator of the herein- 
described type", and 

- figures 5 to 8 are t exemplifying diagrams of the 
operating modes of the herein-described simulator. 
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ft 

Detailed description of an embodiment of the 
invention 

Figure 1 shows the architecture of a simulator 10 
comprising an engine 11 in which all typical 
5 functionalities* for managing the simulation of a 
telecommunications network, such as a radio-mobile 
network, are present, namely: 

- Parameter Manager 11a, 

- Event Scheduler lib, 

10 - Factory Manager 11c, and 

- Statistic Manager lid. 

There is also a device package 12 in which the 
different devices 13 are contained, representative of 
the physical network devices and the objects related to 
15 the scenario to simulate. 

Every devices contains different modules related 
to the different functionalities managed by the device 
itself. 

Such a simulator, working in general among a set 
20 of input signals I and a • set of output signals, can be 
implemented, for instance, on a computer with Intel 
Pentium III processor and Microsoft Windows operating 
system, using Microsoft Visual I Studio 6.0 development 
environment and ANSI C++ programming language. 
25 Always as an example, some possible devices 13 

present in the package 12 are: 

radio-mobile terminal or MS/UE (Mobile 
Station/User Equipment) , 

- node MSC (Mobile- Switching Center) , 

30 - node SGSN (Serving GPRS Support Node) , and 

- node GGSN (Gateway GPRS Support Node) . 

Every device 13 present in the package 12 contains 
in turn the modules related to the different 
functionalities and to the different protocols that it 
35 implements . 
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The modules contained inside devices 13 are 
separated in Control Plane CP and User Plane UP 
modules. The Control Plane CP modules • are related to 
the functionalities of .installation, management and 
5 release . of the connection; the User Plane UP modules 
are r.elated to the communication functionalities when 
the connection is active. 

The solution herein' described focuses, in 
particular, on the Control ' Plane CP characteristics as 
10 regards QoS .functionalities for 2G (second Generation) , 
2.5.G and 3 G (for example GSM, GPRS and UMTS) radio - 
mobile systems . 

The Control Plane modules belong to two families, 
according to the type of connection: Circuit Switched 
15 (CS) (namely as circuit 'switching) or Packet Switched 
(PS) (namely as packet switching) . 

In the CS connection case (see figure 2) , 
attention is focused on modules MT_CC (Mobile Terminal 
Call Control) 21a and MSC_CC (Mobile Switching Center 
20 Call Control) 22b that can respectively be found in two 
devices MS/UE 21 and MSC 22. 

Modules MT_CC 21a and MSC^CC 22.b manage the start 

* 

and release of a call in case of CS (Circuit Switched) 

* 

circuit services ; during the start of a call , said 
25 modules communicate the type of service they need, 
pointing out its* related parameters, to respective 
modules- II and 12 of radio interface GSM or UMTS. 

r 

In device MSC 22 a "module iyiSC__CC 22b is present 

for every active radio-mobile terminal; tlje allocation 

« 

30 of different modules MSC CC 22b is the responsibility 

4 

of a module MSC_CC_Manager 22a. 

The. module MSC_CC_Manager 22a manages different 
typologies of modules MSC_CC 22b, 

Every module typology corresponds to a different 
35 ' QoS profile. Particularly, module MSC_CC_Manager 22a 
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obtains the typology to be use for allocation directly 
from radio-mobile terminal MS/UE 21, where the type of 
module MSC_ CC is stored in an attribute called 
n MSC_CC_CLASS__TYPE. " 
5 In case of PS connection (see figure 3) , the 

attention is focused on modules MT_SM 31a (Mobile 
Terminal Session Management) and SGSN_SM 32b (Serving 
GPRS Support Node Session Management) present in 
respective devices MS/UE 31 and SGSN 32. 

10 Modules MTJSM 31a and SGSN_SM 32b manage the start 

and release of the call in case of PS (Packet Switched) 
packet services; during the start of the call said 
modules communicate the type of service they need, 
pointing out its related parameters, to modules II and 

15 12 of related radio interface GPRS or UMTS. 

In the device SGSN 32 there is a module SGSN_SM 
32b for every active radio-mobile terminal; the 
allocation of different modules SGSN_SM 32b is the 
responsibility of module SGSN_SM_Manager 32a. Module 

20 SGSN_SM_Manager 32a manages' different typologies of 
modules SGSN_SM 32b. 

Every module typology corresponds to a different 
QoS profile. Particularly, module SGSM_SM__Manager 32a 
obtains the typology to be used for allocation directly 

25 from radio -mobile terminal MS/UE 31, where the type of 
module SGSN_SM is stored in an attribute called 
» SGSN_SM_CLASS_TYPE . " 

In every radio-mobile terminal MS/UE, module MT_CC 
21a is present if radio-mobile terminal 21 manages CS 

30 (Circuit Switched) connections; instead, module MT_SM 
31a is present if radio-mobiie terminal 31 manages PS 

.... * * 

(Packet Switched) connections. 

■ 

The above-stated concepts are however well known 
to the skilled experts in the art: the previously- 
35 provided synthesis is primarily aimed therefore to 
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facilitate the correct understanding of the herein 
described arrangement in one of its typical use 
context . 

The. herein described arrangement provides for the 
5 introduction* of a "Quality of Service or QoS .profile" 
of the type shown in figure 4 , aimed to describe the 
parameters related to a type of simulated service. 

With reference to a typical context of radio- 
mobile network, the considered parameters, defined in 
10 the standard (in a way that is largely independent from 
the technology: GSM, GPRS, UMTS, etc.) are as follows: 

- Traffic class 41: one among four possible values 
CONVERSATIONAL, STREAMING, INTERACTIVE, BACKGROUND; 

- Transfer delay 42 : maximum transfer time of a 
15 data unity by transmitter to receiver; 

- Guaranteed bit-rate UL 43: guaranteed transfer 
speed for data that are transmitted by the radio-mobile 
terminal toward the network;* 

- Maximum bit-rate UL 44: maximum transfer speed 
20 for data that are transmitted by the radio -mobile 

terminal tpward the network; 

- Guaranteed bit-rate DL 45: guaranteed transfer 
speed for data that are transmitted by the network 
toward the radio-mobile- terminal; and 

25 - Maximum bit -"rate DL 46: maximum transfer speed 

for data that are transmitted by the network toward the 
radio-mobile terminal. 

A particular QoS profile identifies a type of 
service inside the simulator. 

30 The simulator user can specify in input data the 

■ 

values of parameters of every simulated QoS profile. 

The herein described solution provides 

* 

particularly for the introduction, for every simulated 
user, of a parameter "QoSparams" relative to a 
35 particular QoS profile. 
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In the herein-shown embodiment (that must be 
remembered as such) in modules MT_CC 21a, MT_SM 31a, 
MSC_CC 22b and SGSN_SM 32b a parameter "QoSparams" is 
therefore present that corresponds to a QoS profile 
related to the single radio-mobile terminal: then, 
different radio-mobile terminals MS/UE can have modules 
MT_CC/MSC_CC -or MT_SM/SGSN_SM with different parameters 
"QoSparams", and therefore they can simulate different 
services. It is thereby possible to define for every 
user his customised QoS profile. 

The implementation of parameter "QoSparams" is 
performed in the ANSI C++ programming language by means 
of a class "QoSparams" included as follows: 



15 



20 



class QoSparams 

{ 

public : 

7 / COSTRUCT-DESTRUCT 
QoSparams () ; 
virtual -QoSparams () ; 
virtual void empty () ; 



virtual string toString () const; 



25 



/ / OPERATORS 

virtual void operator = (QoSparams & b) ; 
virtual void operator ' = (QoSparams * b) ; 
virtual void Dump (void) ; 



30 / / METHODS GET 

* 

inline TRAFFIC getTraffic (void) const 
traf f icClass; } 

inline Time gettransf erDelay (void) const 
transf erDelay; } 



{return 



{return 
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inline double getUL_guaranteedBitRate (void) const 
{return UL_guaranteedBitRate ; } 

inline double getDL__guaranteedBitRate (void) const 
{return DL_guaranteedBitRate ; } 

4 * 

5 inline double getUL_maximumBitRate (void) const 

{return UL_maximumBitRate ; } 

inline double getDL_maximumBitRate (void) const 
{return DL_maximumBitRate; } 

inline int getTHP (void) const {return THP ; } 
10 7 / METHODS SET 

inline void setTraffic (TRAFFIC newTraffic) 
{traf f icClass = newTraffic;} 

inline void settransf erDelay (Time newTime) 
{transf erDelay = newTime; } 
15 inline void setUL_guaranteedBitRate (double 

newBitRate) {UL__guaranteedBitRate=newBitRate; } 

■ 

inline void setDL_guaranteedBitRate (double 
newBitRate) {DL_guaranteedBitRate=newBitRate; } 

inline void setUL__maximumBitRate (double 

20 newBitRate) {UL_maximumBitRate=newBitRate ; } 

inline void setDL__maximumBitRate (double 

V 

newBitRate) {DL_maximumBitRate=newBitRate; } 

inline void setTHP(int JTHP) {THP=_THP;} 
/ / SERIALIZE 

25 virtual void serialize (PersistenceManager & p) ; 

■ 

protected: 
/ / MEMBERS 

» 

TRAFFIC traf f icClass ; 

Time transf erDelay ; 

30 . double UL__guaranteedBitRate; 

r 

double DL_guaranteedBitRate ; 

double UL_maximumBitRate ; 

double DL_maximumBitRate; 

int THP ; 

35 
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* 

private : 

/ / 

DECIARE_FACTORY (QoSparams) ; 
/ / 

5 

}; 

» 

4 

The herein described' solution provides for an 
operation able to respect the QoS profile both for 
10 calls "originated" from radio-mobile terminals MS/UE 
and for calls originated from the network (called 
"terminated") . 

In case of an "originated" call of the CS (Circuit 

* 

Switched) type from radio-mobile terminal MS/UE, the 
15 module MT_CC 21a directly sends its own parameter 
"QoSparams" to the module MS.C_CC 22b, that cominunicates 
it to the modules related to radio interface GSM or 
UMTS that * establish the connection according to the 
type of service pointed out in "QoSparams." 
20 Figure 5 refers to the case of an "originated" call 

of the CS (Circuit Switched) type described as follows. 
The call originates in general from a given terminal 
(for instance a i-th terminal Ttfli or a j-th terminal 
TM j ) . 

25 In step 1, the request for starting the connection 

is sent by the radio-mobile terminal toward the 
network, particularly to device MSC; in the starting 
request, module MT_CC 21a in calling terminal inserts 
parameter "QoSparams" with value equal to its own 

30 parameter "QoSparams." 

In step 2 , the device MSC receives the starting 
request and proceeds, through' module MSC_CC_Manager , to 
the allocation of module MSC_CC related to radio-mobile 
terminal MS/UE. Depending on parameter "QoSparams" 

35 received by the device MSC in the starting request, 
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module MSC_CC_ Manager 22a determines the type of module 
MSC_CC to be allocated and allocates it for radio- 
mobile terminal MS/UE. 

In step 3, the method of starting the call towards 
5 terminal TMi or TMj proceeds by using the correct QoS 
profile. 

In case of an "originated" call of the PS (Packet 
Switched) type f rom . radio -mobile terminal MS/UE, the 
operation is analogous to that related to- the 

10 originated call CS : module MT_J3GSN 31a directly sends 
its o^n parameter "QoSparams" to module SGSN_JSM 32b, 
that communicates it to modules related to the radio 
interface GPRS or UMTS, that establish the connection 
according to * the type of service pointed out in 

15 "QoSparams . " 

* 

Figure 6 shows the case of an "originated" call of 
the PS (Packet Switched) type described as follows . 
Also in this case • reference is made to a call 
originated from i - th terminal TMi ( or from j - th 
20 terminal TMj ) . 

In step 1, the starting request of the connection 
is .sent by the radio-mobile terminal towards the 
network, particularly to device SGSN; in the starting 
request, module ' MT_SM 31a in terminal TMi inserts the 
25 parameter "QoSparams" with a value equal to its own 
parameter "QoSparams . " i 

In step 2, the device SGSN. receives the starting 

request and proceeds, through module SGSN_SM_Manager 

32a, to the allocation of module SGSN SM related to 

— 

30 radio-mobile terminal MS/UE. Depending on parameter 
"QoSparams" received by device SGSN in the starting 
request, module SGSN_SM_JVIanager determines the type of 
module to be allocated SGSN_SM and allocates it for 
radio-mobile terminal MS/UE . 
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In step 3, the method - of starting the call from 
terminal Tmi or TMj proceeds using the correct QoS 

■p 

profile . 

In case of "terminated" call the indication of 
5 start of the connection is not sent by radio-mobile 
terminal MS/UE, but originates from simulated network 
devices. The starting request for a connection arrives 
therefore to modules in devices MSC 22 or SGSN 32 
without any indication of what QoS profile to use. 
10 The mechanism shown here as an example allows 

obtaining the QoS profile related to the radio-mobile 
terminal MS/UE to which the call is destined. As 
previously described, modules MSC_CC__Manager 22a and 
SGSN_SM_Manager 32a are respectively able to allocate 
15 different types of modules, respectively MSC CC 22b and 
SGSN_SM 32b, directly obtaining it from radio-mobile 
terminal relative MS/UE (respectively attributes 
"MSC_CC_CLASS_TYPE" and " SGSN_SM_CLASS_TYPE" ) . 

Every type of modules MSC_CC or SGSN__SM is related 

r 

20 therefore to a specific QoS profile . (for instance 
" SGSN_SM_QoS_A is related to module SGSN_SM with* QoS 
profile type A, MSC_CC_QoS__C is, related to module 
MSC_CC with QoS profile type C,...) . 

Figure 7 shows the case of an "terminated" call of 
25 the CS (Circuit Switched) type, described as follows. 

In step 1 7 the starting request of the connection 
reaches device MSC from the network, with the 
indication of its related radio-mobile terminal MS/UE. 

The device MSC sends the request to module 
30 MSC_CC_Manager for allocating module MSC_CC related to 
radio-mobile terminal MS/UE. In step 2, module 
MSC_CC_Manager obtains from radio-mobile terminal MS/UE 
which type of module MSC_CC and allocates it. 

In step 3, the method of call start proceeds using 
35 the correct QoS profile . 



WO 2005/053341 



PCT/IT2003/000783 



16 



Figure 8 finally shows the case of an "terminated" 
call of the PS (Packet Switched) type, described as 
follows. 

i 

in step 1, the starting request of the connection 
5 reaches device SGSN from the network, with the 
indication of its related radio-mobile terminal MS/UE. 

The device SGSN sends the request to module 
SGSN_SM_Manager for allocating module SGSN_SM related 
to radio-mobile terminal MS/UE. In step 2, module 
10 SGSN_SMJVIanager obtains from radio-mobile terminal 
MS/UE which type of module SGSN_SM and allocates it. 

Finally, in step 3, the method of " call start 
proceeds using the correct QoS profile. 

The herein described solution brings about some 
15 essential advantages. 

Firstly, it is possible to define the parameters 
that describe every service from the point of view of 
quality requirements, using in the simulations a 
; quality of service profile for every service that is 
20 desired to simulate. 

It is then possible to define different QoS 
profiles for every simulated user and, accordingly, 
every simulated user can potentially use a different 
service from those used by the other users. The user, 
25 by filling-in his input data I # can then define the 
different services setting the parameters values of the 
QoS profile of every service to simulate. 

Moreover, the operation for managing the QoS 
profiles provides both cases in which simulated calls 
30 are originated from mobile and terminated to mobile. 

In case of simulation of originated calls, 
parameter "QoSparams" is specified by simulated 
terminal to. blocks responsible for starting the 
connection during the connection starting procedure. 
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In case of simulation of finished calls , parameter 
"QoSparams" is adequately taken by the simulated 
terminal from the blocks responsible for starting the 
connection. 

5 The implementation of the described simulator can 

be realized with any type of computer, like Intel, SUN, 
Apple,... and with any operating system (Windows, 
Linux, Unix, MAC OS...). The use of the ANSI C++ 
programming language is only a possible choice since 
10 the implementation can also be performed in other 
programming languages, like Java, Delphi, Visual 
Basic, ... 

The choice of ANSI C++ language appears to be 
currently preferential in view of the good programming 

15 flexibility offered by said programming language and of 
the high level of obtainable performances in the 
finished program in terms of execution speed. 

In the description the term simulated service 
means everything that deals with the transport step of 

20 user data, without needing to consider other service 
steps (set-up, re -configuration, service termination, 
etc.) that can anyway have an impact on the quality 
perceived by users. 

This "approximation" - that must not be read in a 

25 limiting sense for the invention - is suggested by 
different * reasons . 

Firstly, it is usually scarcely practical to 
simulate multiple services in all their steps since 
there are various factors (service architecture, 

30 protocols involved in the various steps, apparatuses 
involved etc.) particular • for the various services that 
can change from implementation to implementation of the 

m 

same service. 

It is usually then scarcely meaningful to perform 
35 simulations on the particular implementations of the 
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various services . since anyway, for reasons of 
modelling, scarcely results would be obtained. 

Nevertheless, the invention can also be used by 
taking into account, on the £asis of present 
5 description, the service steps, as for example set-up, 
re- configuration, service termination, etc. or part of 
them, in cases in which it is useful to consider the 
above steps for evaluating QoS . 

The invention can be used in cellular networks 
10 simulators that simulate other systems besides the 
mentioned GSM, GPRS and UMTS. The invention can be used 
in telecommunications networks simulators of the fixed 
or mixed fixed/mobile types, for instance networks for 
which the management of the quality of service is 
15 provided as described in the present invention. 

The skilled technicians in the field will 
immediately appreciate the fact that the invention does 
not necessarily deals only with the simulation of 
cellular radio-mobile networks: the invention can in 
20 fact be also used in other types of simulators, where 
there is an architecture similar to modules and devices 
complying with real physical equipment and where it is 
necessary to communicate, among the various 
modules/devices, the parameters related to simulated 
25 functionalities . 

It is therefore evident that, having stated the 
principle of the invention, the realisation parts and 
. the embodiments can be widely changed with respect to 
what is described and shown, without anyway departing 

* 

30 from the scope of the present invention, as defined by 
the attached claims. This is valid particularly, but 
not exclusively, as regards the possible extension of 
the herein described solution to simulators in which 
every simulated user is associated with many quality of 

35 service profiles referred to services or classes of 
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different services aimed to mutually interact (for 
instance audio/video streams- aimed to be simultaneously 
exploited) . 



